Google U2F (Gnubby) Documents - 
Snapshot prior to joining FIDO 


Google 





U2F - Universal 2nd Factor 


Web Keychain Device for users 


open Standard strong authentication 
for the web 


Google What we'll cover 


e U2F Overview 

o Problem being solved 

o Value to the end user 

o Value to the Service Provider (RP) 

o Value to the device vendor, integration vendor 
e How U2F works 

o Protocol design considerations 

o Integration into browser 

o More use cases 

o Current Status 
e The larger view: FIDO Alliance 

o Device Centric Auth 

o FIDO offerings as a complementary whole 
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Web passwords are broken 





REUSED PHISHED KEYLOGGED 
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Today's solution: One time codes: SMS or Device 





SMS USABILITY DEVICE USABILITY 


Coverage Issues - Delay - User Cost One Per Site - Expensive - Fragile 





USER EXPERIENCE PHISHABLE 


Users find it hard German Police re: iTan: 
",. we still lose money" 


Google U2F (formerly Gnubby) - pre-FIDO 


Google 


The U2F solution: How itt works 





~ Yf e One device, many services 
e Easy: Insert and press button 
e Safe: Un-phishable Security 
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Google 


Simple for Users 





Userid & Password Insert, Press button Successful Sign in 
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User self-registration 





©) Backup Options A) Registration Done 
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Usage on Mobiles 


Tomorrow 
Tap your NFC-aware 
device to your 
NFC-enabled phone 


(modulo, choosing 
the right app isolation 
tradeoff ... ) 








Today 


Use your computer to 
bless your mobile (one 
time action) 
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Like a real key: Small, Reliable, Secure 





No Batteries Vigorously Tested Secure Element Guarantees 
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U2F Protocol 


Core idea: Standard public key cryptography: 


User's device mints new key pair, gives public key to server 
Server asks user's device to sign data to verify the user. 
One device, many services, "bring your own device" enabled 


Lots of refinement for this to be consumer facing: 


Privacy: Site Specific Keys, No unique ID per device 

Security: No phishing, man-in-the-middles 

Trust: Verify who made the device 

Pragmatics: Affordable today, ride hardware cost curve down 

Speed for user: Fast crypto in device (Elliptic Curve) 

Feature Growth: Server<->device encrypted comm.,; future trusted display 


Think "Smartcard re-designed for modern consumer web" 
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Google 
Under the hood 


e Device core: Secure element accessed over USB or NFC 
e Driverless USB on Win, Mac, Linux, Chrome OS 

o Just plug in and use 
e Direct Access from Browser: 

o Noclient middleware to install 

o Simple Javascript API: "Create Key Pair’ and ‘Sign’ 

o Not just tied to login! Use anytime you want to strongly verify user. 
e Same API on Android 

o Just integrate with your app 
e Ulseen by user completely under server control 
e Server side integrates easily with existing auth services 
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U2F - Universal Second Factor: In a nutshell 


e User carries a strong auth. device, works across services: 
o Small USB/NFC dongle with secure element 
o Works out of box, no software install 
o Mental model "Like a key on your chain, a card in your wallet" 


e For the user: Easy Secure Login 


One device, Many services 

Simple UX - Insert and press button or tap, no software install 
Passwords can be made simple -- 4 digit pins like ATM? 
Very rugged and reliable, like a real physical key 


O O 0 O 


e For the web site: Open Strong Security 


o Open: Not proprietary, multiple vendors, no central service required 
o Self provisioned: No pre-seeding req, "Bring your own token" possible 
o $trong Security: Non-Phishable, Blocks most practical MITMs 

o Strong Privacy: One site cannot use credential given to another 
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Google Other usage models beyond "One key you carry' 


1. Token plugged permanently into home machine 
o husband and wife share 
o husband for paypal and google, wife for schwab and amazon 
2. One token plugged into home, one token plugged into work 
o User provisions both for paypal, can pay from either place 
3. One token plugged into home, one token to carry 
o Convenience, home computer always ready to go 
4. One (tiny) token plugged permanently into work laptop 
© Laptop becomes the 2nd factor (maybe built into next-gen laptops?) 
5. Husband/wife, separate tokens, plugged in simulatenously 
© Each activates own key, protocol has no problem with multiple keys 
6. One account, multiple users, each with own token 
o Small business users share an account with strong auth 
7. Account lockdown to a single device 
o Only one token, plugged into office machine 
8. Same token for work account and personal account 
o Work (= enterprise) leverages user's "bring your own token" 
9. Different token for work account and personal account 


o If enterprise doesn't like self-provision, so ships pre-provisioned token 
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Current Status 


Google "intranet" single sign on is U2F enabled 
o Our "intranet" is directly on the web, so its just web login 
Using a Chrome Extension, step towards browser integration 
o Not using final JS API 
o Integration at "lower" level, but its just eng execution 
Many thousand devices in daily use 
o Compliant devices by Yubico, built around NXP "U2F" secure element. 
o Various software milestones since October 
o Now moving into rapid scaling of Beta 
o Intend to fully replace OTP for employees by end of year 
o Will be ~100,000 units in deployment 
Solving use cases for non-web "legacy" clients 
o Eg, VPN client via Browser extension 
o Weare rolling our own, but fertile ground for ISVs for commercial use 
Glad to help interested RPs to a proof of concept 
o You implement server side with FIDO specs, code fragments 
o Compliant token devices already available 


o Get experience on how the end to end experianca warke 
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Google U2F Schematic 
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Next Section: Larger View: FIDO Alliance 
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Google The Larger View as Google sees it 


e Core need for web service: Ask user for permission 


O 


O 
O 
O 


"You are logging in to create a new session. Please approve" 

"You are deleting all your email. Please approve" 

"You are transferring $100,000 to Sam. Please approve" 

"You are shipping your purchase to a new address. Please approve" 


e Done today with passwords today and maybe OTPs 


O 


Difficult for user, insecure (phishable, MITM, not malware resistant) 


e Megatrend: Users moving to varied personal devices 


O 


O 


User devices have user-specific local authentication (screen lock etc) 
PINs today, biometric on horizon -- many different kinds of local auth. 


e Opportunity: Easy and Secure Web authentication 


O 


O 
O 
O 


Web service asks user for permission 

To approve, user does user-specific local auth on their device 

Web service gets some crypto proof of permission. 

Passwords no longer required for routine aut! °°? “fF Comer Gnubby) - pre-Fibo 


Google A Solution Framework 


« User's device has keystore unlocked by user's local auth 
o Each user of device has own keystore space 
o Devices will have different kinds of local auth (PIN, Various 
biometrics) 


-« User registers device to web service 
o Creates a web service specific key pair 
o Key creation enabled by local auth 
o Hands public key to web service 


« Web service verifies user permission by 
o Asking for signature matching public key 
o User does local auth, unlocks keystore, signs with private key 


« In gist: User does simple auth gesture on personal device to 
easily and securely approve a website's request 


- Very aligned with FIDO alliance's cooste var (tormerly nubby) - pre-FiD0 
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Google How the parts of FIDO fit after Google joins 


e Existing FIDO efforts (technical working group) 
o Larger View, password less, local device auth for sign 
e U2F = Universal 2nd Factor 
o Critical bridge to future, "classic" 2-factor, incremental change for RP 
o Service (RP) password still present, but can be simple (4 digit PIN?) 
e Fit together as one whole for Service Provider (RP) 


Discover user has FIDO passwordless enabled device? 
Register for passwordless experience 

Else offer user FIDO U2F: 

Self-register for simple password + 2 factor experience 





User has FIDO passwordless enabled device + enrollment? 

Give user passwordless "just unlock gesture" experience 
Else user has U2F enrollment? 

Give user simple pwd + "show a 2 factor device" experience 


e Some RPs may want only passwordless, some only U2F 
o That's no problem: FIDO is all about the right choice for RP and user 
o Note that RP can start offering "other" flavor latar caamlacely 
o Same server can talk both passwordless °°°9°77F “omer Gnubby)- preFiDO 


